Some minor corrections needed. Most importantly, the extent does not look right. In EEA SDI spatial catalog is

The extent that you referenced is for a WGS84 bbox. But this data is in native CRS EPSG:3035, and has coordinates in metres and not degrees.

Some minor corrections needed. Most importantly, the extent does not look right. In EEA SDI spatial catalog is

The extent that you referenced is for a WGS84 bbox. But this data is in native CRS EPSG:3035, and has coordinates in metres and not degrees.

But these

  "bbox": [
    -56.5051419017044,
    24.2841770079211,
    72.90613675900907,
    58.95275109308057
  ],
```
are values in degrees, aren't they?

But these

  "bbox": [
    -56.5051419017044,
    24.2841770079211,
    72.90613675900907,
    58.95275109308057
  ],

are values in degrees, aren't they?

@mari-s4e I think you discovered a bug in the catalog-editor (cc @baloola). This WGS84 bbox was generated by the catalog-editor, I only entered the EPSG:3035 coordinates in it (the "x" and "y" in the json).

Our WMS service also reports a WGS84 bbox which matches the one you showed in the previous comment:

                <EX_GeographicBoundingBox>
                    <westBoundLongitude>-56.50514190170437</westBoundLongitude>
                    <eastBoundLongitude>72.9061049341568029565</eastBoundLongitude>
                    <southBoundLatitude>24.28417068794855834328</southBoundLatitude>
                    <northBoundLatitude>72.66326966834436</northBoundLatitude>
                </EX_GeographicBoundingBox>

This is not a bug, catalog editor reprojects the X & Y dimensions extnets to WGS84 and generates the bbox, according to stac item spec (same goes for the geometry as well)

@baloola there is a bug because the generated northBoundLatitude is 58.95275109308057, but it should be 72.66.

The problem is likely that you transform individual coordinates which is incorrect (cc @bangph for pointing this out). This can be verified with gdaltransform:

$ gdaltransform -s_srs EPSG:3035 -t_srs EPSG:4326
Enter X Y [Z [T]] values separated by space, and press Return.
7400000 5500000
72.906136759009 58.9527510923263 0

It gives 58.952 like the catalog-editor and not 72.66.

The correct way is to transform the whole bbox, e.g. with gdalwarp:

1. Create a bbox_epsg3035.vrt file with content

<VRTDataset rasterXSize="650000" rasterYSize="460000">
  <SRS>EPSG:3035</SRS>
  <GeoTransform>900000, 10, 0, 5500000, 0, -10</GeoTransform>
  <VRTRasterBand dataType="Byte" band="1">
    <NoDataValue>0</NoDataValue>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">dummy.tif</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="1" RasterYSize="1" DataType="Byte" BlockXSize="1" BlockYSize="1"/>
      <SrcRect xOff="0" yOff="0" xSize="1" ySize="1"/>
      <DstRect xOff="0" yOff="0" xSize="1" ySize="1"/>
    </SimpleSource>
  </VRTRasterBand>
</VRTDataset>

2. put whatever dummy.tif file in the same directory
3. check the bbox with gdalinfo:

Origin = (900000.000000000000000,5500000.000000000000000)
Pixel Size = (10.000000000000000,-10.000000000000000)
Corner Coordinates:
Upper Left  (  900000.000, 5500000.000) ( 56d30'18.51"W, 56d29' 4.75"N)
Lower Left  (  900000.000,  900000.000) ( 23d49'33.58"W, 24d17' 3.04"N)
Upper Right ( 7400000.000, 5500000.000) ( 72d54'22.09"E, 58d57' 9.90"N)
Lower Right ( 7400000.000,  900000.000) ( 40d39'45.75"E, 25d32'40.96"N)

4. reproject the file:

gdalwarp -t_srs EPSG:4326 -of VRT bbox_epsg3035.vrt bbox_epsg4326.vrt

5. check the result bbox with gdalinfo bbox_epsg4326.vrt:

Origin = (-56.505141901704370,72.663269668344356)
Pixel Size = (0.000128060211603,-0.000128060211603)
Corner Coordinates:
Upper Left  ( -56.5051419,  72.6632697) ( 56d30'18.51"W, 72d39'47.77"N)
Lower Left  ( -56.5051419,  24.2841707) ( 56d30'18.51"W, 24d17' 3.01"N)
Upper Right (  72.9061049,  72.6632697) ( 72d54'21.98"E, 72d39'47.77"N)
Lower Right (  72.9061049,  24.2841707) ( 72d54'21.98"E, 24d17' 3.01"N)

@mari-s4e FYI I created a separate issue for the bbox problem.

I don't think it's practical that I go through some 30 jsons and fix these bboxes manually - I expect this to be fixed in the catalog separately, as it probably affects already published catalog entries as well. So I suggest to ignore the bbox in this and other reviews until that issue is solved.